Palo Basic Setup

A run through using the CLI to set up a Palo firewall at home covering the initial configuration, upgrading, BGP routing and a basic firewall policy.

Similar to Cisco software the CLI has two modes of operation:

In general when issuing show commands (interfaces, sessions, etc) they are displayed as a table unless a specific object is specified (such as an interface) with the result being a lot more detail on that object (non-table view). Any commands that take follow will show the data in realtime, kind of like tail -f does in linux.

Using tab or ? in a command shows all the possible options, + is an option and > means that there are further sub-options.

find is a super useful command similar to a wiki that lets you search all cli commands (show, set, clear, etc) that contain the keyword.

Request commands are run in operational mode and are used for displaying system information and performing system-level tasks such as licensing, upgrades, plugins, High-availability and reboots.

Within operational mode the XML formatted running config can be viewed with the optional use of xpath (xpath is a WCS standard) to filter this down to different sections.

Within configuration mode the per-section configuration (includes non-committed changes) can be viewed as xml (default), json or a more traditional per line output with set. This setting is per-console session, it does not survive the console session.

For any tasks (upgrades, commit, etc) that are been processed or have previously performed can check the progress and status using show jobs.

For normal administrative operations the CLI is set to interact and provide feedback in the form of auto-completion and error messages if a command is incorrect or there are invisible line breaks. scripting mode is useful for entering long lists of set commands as it disables interaction (no auto-complete or error messages) and suppresses special characters to help to prevent pasted config failing because of one-line errors.

When a Palo boots up it takes a while for the services to startup meaning you can SSH in pretty quickly but user authentication will fail with a wrong password message until the services have finished starting.

Change management interface from DHCP to static, turn off password complexity (does not apply to admin password) and add a user (prompts for password). If you wish all the commands for a configuration section can be chained into the one line rather than split across multiple lines.

Set the base management configuration, this is in its own routing table separate from any firewall virtual-routers (VRFs).

To view settings (in xml or as flat config lines if have changed cli config-output-format) before applying.

Add management profiles (what protocols are allowed to interfaces), interfaces, zones and the default gateway. Similar to a VRF Palos use the concept of virtual-routers to allow for multiple separate routing tables which each hold member interfaces and routing elements.

In this example the configuration is all under the default virtual-router.

Without leaving configure mode you can check the operational state by prefixing operation show commands with run.

To configure an interface to use DHCP for its IP address and default route rather than being statically assigned.

Mistakes can undone by using delete, for example to delete a zone and re-add.

Commands for checking the system, interfaces and connectivity.

Licensing is based on feature-set and CPUs (2 vCPU VM-100 is 16.5 credits) meaning that if a VM has more vCPUs than you want to license the number used must be limited for firewall registration. A reboot is required for this to take effect.

NGFW credits are assigned via a deployment profile within Palo portal » Assets » Software Credits and the resulting auth-code applied on the firewall. Can mix and match features and CPUs to be more granular on the number of credits used.

It is a good idea to make sure the FW can ping the Palo licensing site before doing the registration. Upon registration FW services are restarted meaning the console session will be closed, when you log back in will get the usual wrong password messages until all services have restarted.

When deleting a firewall you should first deactivate it in the portal so that the credits are returned to the deployment profile (can still be done if the firewall is offline). If the firewall is to be re-licensed rather than destroyed you have to also do the deactivation on the firewall, if you dont it will fail the new activation with the message “Server error : Failed to install licenses. Invalid serial number”.

The Palos need to be licensed to be able to check for updates, without it you will get a generic connection failure error. PAN-OS comes in:

When upgrading across multiple major versions (8.1 to 9.0 to 9.1) you must upgrade to the next major version before moving on to the one after it (can’t skip a major version). When upgrading to the latest maintenance release from an earlier maintenance version (9.1.1 to 9.1.10), you do not need to install any intermediary maintenance versions.

The firewall has two system volumes that contain a fully installed PAN-OS of which only one partition is active. The inactive partition either contains the previously installed version or the next version if you have just installed it but not rebooted yet. The upgrade process is similar to F5s where you install the new version on a different partition and boot to that partition.

Check for latest updates and download the required version. Use show jobs to keep track of the download process (all or id).

Once downloaded the new image will be in maint ready to be installed on a partition, the RUNNING-ACTIVE partition is the current version.

Install the downloaded image onto the sysroot1 a partition, once again can keep an eye on the progress by viewing the job.

Once the installation has finished it will be in a PENDING-CHANGE state.

Reboot the firewall to complete the upgrade.

As it uses partitions the rollback process is fairly straight forward, you just have to switch the boot partition.

Revert the update by activating the previous partition and rebooting.

Below are some useful commands when looking at versions. svm stands for Pan Software Manager, you can see its options using debug swm *.

By default the firewall uses its management interface to communicate with the various management services such as licensing, updates, DNS, email, User-ID agent, syslog, Panorama, etc. Service routes allow you to choose which interface is used on a per-service basis. Only an interface with a statically assigned IP addresses can be used for service routes, it wont give you the option of IP or interface if that interface is using DHCP.

Change paloalto-networks-services so that ethernet1/1 rather than the management interface is used for software updates and licensing.

It is also possible to same thing for a specific destination IP or URL rather than a defined service.

For a firewall the BGP options available in Palo are pretty impressive, communities (including regex matching) as well as other BGP attributes such as weight, local preference, MED, AS-path, origin and next-hop are all supported in some form. The only thing missing is some sort of multi-VRF address-family like MPLS-VPN or EVPN, but is probably a step too far for a firewall. BFD is possible on higher license models, I tried on a VM-100 but got the error “BFD profile ‘default’ can not be enabled as bfd is not supported on this platform.(Module: routed)". BGP and BFD (if used) need to be explicitly allowed in the firewall security policy.

By default any prefixes learnt via BGP including the default route will not be put in the routing table, this is configured under the general settings.

Peer groups are a collection of BGP peers that share settings and advertisements. Route-reflector configuration would be done under peers on a per-peer basis. There are 4 types of peer-groups (ebgp, ebgp-confed, ibgp, ibgp-confed) with the main difference being the next-hop options.

Create an iBGP peer, installs the BGP routes into the routing table and allow for dynamically updating the BGP routing table when routing changes are made (soft-reset-with-stored-info). Each peer must specify a local-address interface or IP (if multiple IPs on interface).

It is worth noting that when you commit BGP changes it flaps the BGP peerings.

There are 5 types of advertisement, import, export, conditional advertisement and aggregates are associated to a peer-group (aggregates can also be associated to a peer) and redistribution (redist-rules) applied to the whole BGP process.

Redistribution profiles allow static routes or other routing protocols to be advertised on a priority basis with conditional filtering. The priority of the redistribution profiles (lower priority profiles are matched first) allows for redistributed route inclusion or exclusion. All redistribute profiles must have an action of redistribute or don’t redistribute for the matched filter. If only 1 prefix needs to be redistributed this can be done without the need for a redistribution profile.

Each redistribution profile is associated to the BGP process (where priorities come in) and BGP attributes set (by default set-origin is incomplete).

Advertise the RFC1918 ranges and a default route into BGP using static Null routes and allow-redist-default-route.

Some routing show commands, the virtual-router can be added to most of these commands to limit it to a specific routing table

Tags can be used for multiple purposes, I have used them to colour address and address-groups within the security policy, define membership within dynamic address-groups and to group rules within the different policies. Each object can have up to 64 tags, when an object has multiple tags it displays the color of the first tag applied.

An empty address group cant be created, the commit will fail with “Error: Fail to count address groups”. As per most set commands, to define multiple objects within a command use [] to define the list with each list object separated by a space.

There are multiple actions that handle inbound connections, some of which are stealthy and some of which are noisy and informative. If you check Send ICMP Unreachable and the ingress interface is Layer 3, an ICMP Unreachable packet is sent to the client for all of the dropped sessions.

The default action for new security rules is to allow traffic and log once the session is closed (Log at session end). I only really choose Log at session start if I am doing testing.

By adding group-tag to the security rules Group rules by tags can be used within the GUI to view the rulebase in categories based on this tag value. While viewing the rulebase as groups the policy order and priority is maintained meaning that if tagged rules are not sequential the categories will not contain all rules (will be multiple categories of same name in different places).

By default every security policy has 2 default catch-all rules, if changed a red cog indicates that the default setting has been overridden.

Can move rules around (with after, before, bottom, top) or delete them.

Security policy objects can be viewed from operation or configuration mode.

The source and destination zone for inbound NAT are determined before the NAT policy is evaluated which means the source and destination zone will always be identical. For inbound NAT the source zone will reflect the interface that the clients are connected to and the destination zone the egress interface that a routing lookup determines based on the original packet.

Hide NAT (Dynamic IP and Port (DIPP)) supports around 64,000 concurrent sessions per available source IP, multiplied by the oversubscription factor supported by the platform. As a rule of thumb, smaller platforms commonly support 2x oversubscription, larger platforms support 4x, and extra-large platforms up to 8x (use show running nat-rule-ippool rule to check oversubscription).

Alternatively Hide NAT can use the interface IP address instead of a dedicated IP addresses.

As per security rules the NAT policy can also be grouped and displayed in the GUI using tags, the show comand syntax is also very simialr.

https://weberblog.net/cli-commands-for-troubleshooting-palo-alto-firewalls/ https://live.paloaltonetworks.com/t5/general-topics/quot-set-cli-terminal-height-500-quot-not-work/td-p/391630 https://itsecworks.com/2013/12/10/palo-alto-troubleshooting-commands/ https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000Clfi https://docs.paloaltonetworks.com/pan-os/9-1/pan-os-web-interface-help/objects/objects-tags/create-tags https://docs.paloaltonetworks.com/vm-series/10-1/vm-series-deployment/license-the-vm-series-firewall/software-ngfw/limit-licensed-vcpus https://www.thegeekstuff.com/2020/06/paloalto-panos-upgrade/ https://docs.paloaltonetworks.com/pan-os/10-1/pan-os-cli-quick-start/use-the-cli/modify-the-configuration